RODO w IT

Nowe Rozporządzenie w zakresie ochrony danych osobowych (GDPR/RODO) wymaga, aby system został zaprojektowany adekwatnie do ryzyka związanego z przetwarzaniem danych osobowych. Aby sprostać wymaganiom jednym z elementów Audytu przygotowującego do wdrożenia RODO powinna być weryfikacja posiadanych systemów w tym aplikacji w kierunku podatności mogących mieć wpływ na wyciek danych osobowych.

Trzeba również pamiętać, iż Rozporządzenie wymaga, aby środowisko było w sposób ciągły poddawane testom na podatności.
W celu wykonania analizy podatności i zagrożeń aplikacji, dla których posiadamy prawa autorskie, możemy skorzystać z rozwiązań pozwalających na wykonanie statycznej analizy kodu źródłowego. Wskażą nam one miejsca gdzie aplikacja jest napisana w sposób niezgodny ze standardami bezpieczeństwa. Rozwiązania te określą nam luki oraz zagrożenia wraz z możliwością ich poprawy. Analizę taką należy wykonywać w każdym momencie, gdy wprowadzamy zmiany do aplikacji oraz za każdym razem, gdy pojawia się nowa wersja oprogramowania, którym dokonujemy statycznej analizy kodu, ponieważ wraz z nową wersją implementowane są nowo poznane podatności.

W przypadku, gdy aplikacja jest dostarczana przez dostawcę zewnętrznego i nie posiadamy praw autorskich do kodu możemy żądać raportu ze statycznej analizy kodu źródłowego przez dostawcę. Raport taki powinien być udostępniony zarówno na etapie pierwszego audytu jak i później okresowo w trakcie użytkowania aplikacji.

W fazie wyboru aplikacji należy zadbać o to, aby software house, który ma dostarczyć dla nas aplikacje wytwarzał je w środowisku Secure-SDLC. Takie podejście gwarantować powinno zaimplementowanie wymagań GDPR związanych z privacy/secure by design po stronie software house’u i weryfikację jakości kodu aplikacji pod kątem bezpieczeństwa, właściwe zarządzanie zmianą oraz możliwość reagowania na nowo wykryte podatności.

Z jakich rozwiązań korzystać dla procesu statycznej analizy kodu ?

Na pewno powinny być to rozwiązania komercyjne, dzięki którym jesteśmy wstanie w razie nieszczęśliwego zdarzenia udowodnić, iż dopełniliśmy należytej staranności w procesie wytwarzania czy odbioru aplikacji. Rozwiązanie ma wspierać odpowiednie, uznane standardy bezpieczeństwa OWASP TOP-10, SANS-25, czy PCI-DSS dla aplikacji mających dostęp do systemów transakcyjnych. Producent powinien jak najczęściej udostępniać nowe wersje oprogramowania, biorąc pod uwagę jak często pojawiają się informacje o nowych podatnościach. Wydaje się, iż niezbędne minimum to update cztery razy do roku.

Jeżeli będziemy realizować statyczną analizę kodu źródłowego we własnym zakresie to rozwiązanie musi być dla nas jak najbardziej przyjazne, nie powinno wymagać dużego nakładu pracy na konfigurację, ma dawać możliwość szybkiego i łatwego przeglądu znalezionych podatności oraz umożliwiać testy inkrementalne tak, aby skrócić czas oczekiwania na wynik. Ponadto musimy mieć możliwość konfiguracji naszych wymagań biznesowych względem aplikacji takich jak ograniczanie liczby danych przetwarzanych w aplikacji.

Pamiętać należy, że mamy prawo umieścić odpowiednie zapisy w procesie zakupowym, tak, aby na etapie procesu zakupowego odpowiednimi zapisami w umowie zagwarantować sobie, że wykorzystywane oprogramowanie będzie pozbawione podatności i możliwość wycieku danych z aplikacji. Dostarczenie aplikacji jest swego rodzaju outsourcingiem.

Podsumowując mamy obowiązek:

1. w architekturze IT w procesie dostarczania aplikacji uwzględnić statyczną analizę kodu źródłowego;
2. dokonać przeglądu umów z zewnętrznymi software house’mi i umieścić w nich stosowne zapisy;
3. testować okresowo aplikacje do których posiadamy kody źródłowe;
4. wymagać dostarczenia stosownych raportów od zewnętrznych dostawców.

Niezależnie od tego czy mamy do czynienia z małą firmą, czy dużą korporacją, liczba incydentów związanych z bezpieczeństwem rośnie z roku na rok. Wszystkie incydenty potrzebują skutecznego zarządzania. W szczególności te, które skutkują koniecznością sięgania po środki nadzwyczajnej rangi, takie jak plany utrzymania ciągłości działania firmy. Jak zatem skutecznie monitorować i przeciwdziałać incydentom bezpieczeństwa?

Rozważania warto rozpocząć od przyjrzenia się narzędziom, które mogą okazać się pomocne w skutecznym wykrywaniu incydentów, ich segregacji, ich ograniczeniu i reagowaniu na nie. Rozwiązania, których wdrożenie może mieć istotny wpływ na bezpieczeństwo systemów IT, można podzielić na siedem klas narzędzi:

1. Ochrona

Jedną z pierwszych linii obrony przed atakami, tuż za zaporami sieciowymi, stanowią systemy klasy IDS/ IPS (Intrusion Detection and Prevention Systems). Mają one za zadanie w czasie rzeczywistym monitorować aktywność sieci i serwerów pod kątem wykrywania prób potencjalnych włamań i naruszeń bezpieczeństwa. Działanie tych systemów opiera się na analizie sygnaturowej i heurystycznej pakietów danych oraz porównaniu ich do znanych typów ataków. W przypadku wykrycia aktywności uznanej za złośliwą, system ma możliwość zablokowania takiej transmisji.

Aplikacje webowe możemy chronić dodatkowo systemami klasy WAF (Web Application Firewall). Praca tych systemów polega na sprawdzaniu żądań HTTP, a następnie dzięki zestawowi reguł, np. obejmujących luki OWASP Top 10, blokowaniu takiego ruchu lub jego przepuszczaniu. Przykładowymi atakami z OWASP Top 10 są np. SQL injection czy XSS.

Wśród popularnych narzędzi typu IDS/ IPS znajdują się Snort, OSSEC, natomiast narzędziem typu WAF jest ModSecurity.

2. Logi

Dzienniki aktywności są bogatym źródłem informacji o tym, co dzieje się w naszym środowisku IT, w szczególności w sieci i systemach. W praktyce przeglądanie każdego dziennika z osobna jest skrajnie nieefektywne i nie pozwala na sprawne wyciąganie sensownych wniosków. Tym bardziej, że z reguły odpowiedzialność za te przeglądy jest rozproszona na wiele osób, np. administratorów poszczególnych systemów i urządzeń. W takich sytuacjach warto stosować systemy zwane SIEM (Security Information and Event Management). Zadaniem SIEM jest zebranie w jednym miejscu wszystkich logów i ich analiza jednocześnie z korelacją zdarzeń pomiędzy nimi. W efekcie otrzymujemy spójny i przejrzysty obraz sytuacji, a co więcej, wszelkie zagrożenia są wychwytywane w dużo szybszym tempie.

Przykładem narzędzia typu SIEM jest OSSIM.

3. Sprawdzanie podatności

Automatyczne skanery podatności identyfikują potencjalne luki w systemach IT, dzięki czemu można na czas wdrożyć działania naprawcze. To pozwala w znaczący sposób minimalizować obszary ryzyka. Działanie skanerów opiera się na sprawdzeniu czy wersje komponentów wykorzystywanych przez nasze systemy znajdują się w bazie znanych podatności CVE (Common Vulnerabilities and Exposures).

Przykładem takiego skanera jest OpenVAS.

4. Monitoring

Niezbędne jest stałe monitorowanie wszystkich krytycznych komponentów infrastruktury w tym aplikacji, usług, systemów operacyjnych, protokołów sieciowych, wybranych wskaźników czy infrastruktury. Monitorowanie dostępności jest niezwykle ważne i pomocne, ponieważ przerwa w działaniu aplikacji lub usług może być pierwszą oznaką incydentu bezpieczeństwa.

Przykład narzędzi: Nagios, Zabbix.

5. Inwentaryzacja sieci

Rozumienie swojego środowiska IT pozwala skutecznie reagować na zagrożenia płynące z sieci wewnętrznej. Najlepszym sposobem na to jest automatyczne wykrywanie zasobów i ich inwentaryzacja. Dzięki temu rozwiązaniu wiemy ile i jakie urządzenia są obecne w sieci oraz jakie oprogramowanie jest na nich zainstalowane. Pozwala nam to na eliminowanie źródeł potencjalnych ataków, np. niewspierane lub nieaktualne wersje systemów operacyjnych i programów, zanim faktycznie do nich dojdzie.

Przykład narzędzia: OCS Inventory.

6. Materiały dowodowe

W przypadku, gdy dojdzie już do incydentu bezpieczeństwa istotne jest sprawne zidentyfikowanie, odzyskanie, zachowanie i analiza sekwencji wydarzeń, które do niego doprowadziły. Ma to kluczowe znaczenie dla zidentyfikowania i naprawienia pierwotnej przyczyny. Zgromadzone dowody mogą również wspierać wszelkie działania dyscyplinarne lub prawne, np. zawiadomienie odpowiednich służb i organów nadzorczych.

Przykłady narzędzi: SANS SIFT, Sleuthkit.

7. Człowiek

System klasy Service Desk może mieć kluczowe znaczenie w organizacji w zakresie informowania służb IT o potencjalnych źródłach incydentów. Najbardziej podstawową formą kontroli bezpieczeństwa jest wykształcony i świadomy pracownik. Użytkownicy powinni być świadomi swoich obowiązków i sposobu w jaki mogą zgłaszać incydenty i reagować na nie. Co więcej powinni być wręcz zachęcani do zgłaszania wszelkich słabych punktów związanych z bezpieczeństwem tak szybko jak to możliwe.

Przykładem narzędzia do obsługi zgłoszeń jest OTRS.

Podsumowanie

Ochrona przed cyberzagrożeniami staje się poważnym problem dla wielu organizacji. Dlatego przedstawione propozycje narzędzi typu open source mogą stanowić filar budowy systemu zarządzania incydentami bezpieczeństwa. Oczywiście nic nie stoi na przeszkodzie, aby sięgać po rozwiązania komercyjne. Niezależnie jednak od tego, jakie systemy zdecydujemy się zaimplementować wewnątrz naszej organizacji, ważne jest, aby stale śledzić i monitorować informacje o nowych zagrożeniach jakie pojawiają wokół nas.

Źródło: „Magazyn ODO” 2018

Obserwując rynkowe trendy można stwierdzić, iż korzystanie z usług przetwarzania danych w chmurze (ang. cloud computing services) cieszy się rosnącą popularnością wśród klientów, niezależnie od wielkości przedsiębiorstwa. Przyczyną takiego stanu rzeczy są zalety tego modelu świadczenia usług, do których zaliczają się m.in.: zapewnienie wysokiej dostępności i bezpieczeństwa danych, elastyczność i skalowalność zasobów, niższe koszty całkowite (TCO, ang. Total Cost of Ownership), możliwość wyeliminowania kosztów inwestycyjnych (CAPEX), czy też przerzucenie „problemu” utrzymania systemów i związanych z tym czynności na dostawcę (zarządzanie, aktualizacja, back-up).

Mimo szeregu zalet użytkownicy mają liczne obawy przed migracją do środowiska chmury. Według badań przeprowadzonych przez Audytel, najwięcej wątpliwości wzbudzają kwestie związane z bezpieczeństwem i ochroną danych poufnych, utratą kontroli nad danymi, a także brakiem zgodności z normami i regulacjami.

W rzeczywistości obawy te mogą okazać się zupełnie nieuzasadnione, zwłaszcza w przypadku klientów z sektora MŚP. Model przetwarzania danych w chmurze w praktyce może zapewnić  znacznie wyższy poziom bezpieczeństwa w stosunku do przetwarzania danych we własnej infrastrukturze w siedzibie firmy (ang. on premise). Dzieje się tak dlatego, że profesjonalni dostawcy usług chmurowych dysponują szeregiem zabezpieczeń zarówno na poziomie technicznym, jak i organizacyjnym, których zwłaszcza małe przedsiębiorstwa zazwyczaj nie stosują, lub stosują w ograniczonym zakresie. Ponadto operator platformy cloud jest w stanie zapewnić szereg usług dodatkowych takich jak back-up danych, odtworzenie danych w przypadku awarii (DRC), co przyczynia się do zwiększenia dostępności danych w stosunku do przetwarzania lokalnego.

Ze względu na zwiększony poziom bezpieczeństwa danych, możliwość zapewnienia wysokiej dostępności (zgodnie z  wymaganiami  RODO – artykuł 32), usługi chmurowe stanowią szansę na spełnienie tych wymagań, zwłaszcza dla podmiotów które nie są w stanie im sprostać w samodzielnie budowanym i zarządzanym środowisku IT. Dodatkowo operator usługi cloud powinien, w ramach swoich możliwości zapewnić wsparcie przy realizacji innych wymagań wynikających z rozporządzenia, takich jak notyfikacja o incydentach oraz realizacja żądań wynikających z uprawnień podmiotów danych (szczególnie w przypadku usług typu Software as a Service – SaaS).

Na co zatem zwrócić uwagę przy korzystaniu z usług dostawców chmurowych w aspekcie RODO?

Przede wszystkim należy określić, czy dostawca będzie miał dostęp do przetwarzanych danych osobowych. W przypadku świadczenia usługi w modelu IaaS (ang. Infrastructure as a Service), tak być nie musi. Jednak w najpopularniejszym obecnie modelu usług chmurowych czyli SaaS usługodawca będzie miał dostęp do przetwarzanych danych, zatem w rozumieniu RODO  będzie podmiotem przetwarzającym, ze wszystkimi tego konsekwencjami. Zgodnie z artykułem 28 RODO, usługodawca w szczególności zobowiązany będzie do zachowania tajemnicy, zapewnienia bezpieczeństwa przetwarzanych danych osobowych poprzez podjęcie środków określonych w artykule 32, wsparcia administratora w realizacji żądań praw podmiotów danych oraz wywiązywania się z pozostałych obowiązków wynikających z RODO. Sposób, zakres, czas, charakter czy cele przetwarzania danych przez usługodawcę powinny być uregulowane na podstawie umowy powierzenia lub innego instrumentu prawnego wiążącego prawnie administratora i podmiot przetwarzający. Ważne by umowa określała konkretnie rodzaj przetwarzanych danych osobowych, kategorie osób, których dane dotyczą oraz wszystkie szczegółowe obowiązki oraz prawa administratora i podmiotu przetwarzającego.

Inną kwestią, na którą należy zwrócić uwagę, jest lokalizacja przetwarzania danych. Co do zasady, za bezpieczne uznaje się kraje znajdujące się na terenie Europejskiego Obszaru Gospodarczego (EOG), na terenie którego obowiązują przepisy RODO. Nie ma przeciwwskazań do przekazania danych osobowych dostawcy przetwarzającemu je poza obszarem EOG, pod jednym jednak warunkiem –  zapewnienia odpowiedniego stopnia ochrony danych, co zgodnie z art. 45 RODO, potwierdza w drodze aktu wykonawczego (decyzji) Komisja Europejska.

W przypadku gdy Komisja Europejska nie wydała decyzji co do odpowiedniego stopnia ochrony na danym obszarze, nadal istnieje możliwość zawarcia umowy z dostawcą przetwarzającym tam dane. Należy jednak zbadać stosowany przez dostawcę rodzaj zabezpieczeń, środki ochrony prawnej oraz możliwości egzekwowania praw osób, których dane dotyczą. Dostawcy posiadający m.in. zatwierdzone wiążące reguły korporacyjne, lub otwarci na zastosowanie w umowie powierzenia  standardowych klauzul ochrony danych przyjętych przez Komisję Europejską, lub też posiadający zatwierdzony kodeks postępowania, lub zatwierdzony mechanizm certyfikacji będą podmiotami przetwarzającymi, które spełniają wymóg zapewnienia adekwatnego poziomu ochrony danych.

Podsumowując, przy wyborze dostawcy usług chmurowych przede wszystkim należy mieć na uwadze aspekty bezpieczeństwa. Wskazówką mogą być tu certyfikaty posiadane przez usługodawcę, jak na przykład ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, czy też przynależność do organizacji zrzeszających, jak na przykład CISPE. Atutem mogą też być usługi dodatkowe jakie zapewnia dostawca, jak na przykład ochrona przed złośliwym oprogramowaniem, atakami DDOS, itp. Inną ważną kwestią jest fizyczna lokalizacja przetwarzanych danych. Jeżeli przetwarzanie odbywa się poza terytorium EOG niezbędna jest weryfikacja czy dostawca gwarantuje odpowiedni stopień ochrony danych, bez względu na lokalizację ich przetwarzania. Należy też pamiętać, że administratorowi – w każdym momencie korzystania z usługi – przysługuje prawo do kontroli podmiotu przetwarzającego, mającej na celu wykazanie czy należycie realizuje on swoje obowiązki.

Mechanizm bezpieczeństwa w postaci szyfrowania danych został wprost wymieniony w art. 32 RODO jako przykład rozwiązania służącego ochronie danych osobowych przed ryzykiem naruszenia praw lub wolności osób fizycznych.

Ustawodawca nie przedstawił jednak bardziej szczegółowych wytycznych wskazujących w jakich sytuacjach oraz przy użyciu jakich metod zabezpieczenia te powinny być implementowane. Administratorowi danych nie pozostaje zatem nic innego, jak odwołać się do „najnowszego stanu wiedzy” w zakresie dostępnych rozwiązań oraz wyniku szacowania ryzyka w celu oceny adekwatności ich stosowania.

Przyjrzyjmy się zatem kilku najczęściej występującym sytuacjom:

• Strona www wystawiona do sieci internet. W takim wypadku niewątpliwie należy zastosować ochronę danych w tzw. locie (data in transit), poprzez zastosowanie szyfrowanej transmisji https, wykorzystującej:
  1. Protokół tls w wersji co najmniej 1.2.
  2. Klucze publiczne wykorzystujące krzywe eliptyczne efemeryczne.
  3. Szyfr RSA co najmniej AES128 z GCM.
  4. Funkcję skrótu co najmniej SHA256.

Jeśli dostęp do bazy danych możliwy jest bezpośrednio z sieci internet to dane w spoczynku (data in rest) powinny zostać zaszyfrowane w bazie. Rodzaj zastosowanego szyfru zależy tutaj od ważności danych, tj. przykładowo dane zaszyfrowane w 2010 roku AES128 będą narażone na odszyfrowanie w 2030 roku.

• Aplikacja działająca wewnątrz sieci lokalnej wykorzystująca bazę SQL. Ze względu na to to, że ryzyko włamania do bazy jest tutaj minimalne, szyfrowanie danych w samej bazie na ogół jest zbędne.
• Poczta email. Powszechnie stosowane są dwa standardy bezpiecznej wymiany poczty email. Pierwszy oparty jest na mechanizmie certyfikatów x.509. Drugi wykorzystuje rozwiązanie PGP (Pretty Good Privacy) lub jego otwartą implementację GPG (GNU Privacy Guard). W obu przypadkach, aby wysłać bezpieczny email do odbiorcy, należy znać jego klucz publiczny, co czyni rozwiązanie mało elastycznym. Alternatywą może być wykorzystanie do ochrony zawartości poczty email za pomocą serwera, praw dostępu RMS (Rights Management System), którego zadaniem jest zarządzanie prawami dostępu do określonych dokumentów. Dzięki temu rozwiązaniu mamy możliwość nie tylko określania praw dostępu do poszczególnych dokumentów, ale również okresu ich ważności.
• Urządzenia mobilne. Ze względu na wysokie ryzyko zgubienia lub kradzieży urządzeń, pamięć wewnętrzna powinna być szyfrowana za pomocą co najmniej AES128.

Zgodnie z artykułem 32 RODO, administrator i podmiot przetwarzający dane osobowe wdrażają odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający występującemu ryzyku, w tym między innymi pseudonimizację i szyfrowanie danych osobowych.

Technikami, które pozwalają na utrzymywanie korzyści z posiadania danych oraz minimalizują ryzyko w związku z utratą prywatności, jest anonimizacja lub pseudonimizacja. Mimo wykorzystania zaawansowanych algorytmów, stworzenie prawdziwie anonimowego zbioru danych przy jednoczesnym zachowaniu użyteczności informacji, nie jest prostą operacją. Istnieje ryzyko, że zbiór danych uznany za anonimowy może być połączony z innym zbiorem danych w taki sposób, że możliwe będzie zidentyfikowanie jednej lub więcej osób.

Wyróżnia się dwie główne techniki depersonalizacji danych osobowych. Jest to anonimizacja oraz pseudonimizacja. Największa różnica między nimi polega na tym, że pseudonimizacja jest procesem odwracalnym, a anonimizacja już nie.

Rysunek 1. Techniki depersonalizacji danych

Źródło: Opracowanie własne.

Pseudonimizacja jest to odwracalny proces, polegający na zastąpieniu danej rzeczywistej nazwą przybraną, czyli nadanie jej tak zwanego pseudonimu. Pseudonimizacja utrudnia identyfikację, natomiast umożliwia przypisanie różnych czynności tej samej osobie (bez znajomości jej danych osobowych) oraz łączenie rożnych zbiorów danych między sobą. Pseudonimizacja skutecznie podwyższa bezpieczeństwo przetwarzania danych, ale nie jest równoznaczna anonimizacji w związku z czym, dane poddane pseudonimizacji dalej podlegają pełnej ochronie.

Poniższy rysunek prezentuje podział pseudonimizacji na pięć głównych kategorii.

Rysunek 2. Podział technik pseudonimizacji

Źródło: Opracowanie własne.

Najczęściej stosowanymi technikami pseudonimizacji są:

• Szyfrowanie za pomocą tajnego klucza – dane osobowe są nadal przechowywane w zbiorze danych, ale w formie zaszyfrowanej. Posiadanie klucza szyfrującego pozwala na pełen dostęp do danych osobowych. Używając szyfrowania, które zachowuje aktualne standardy bezpieczeństwa, możliwość odszyfrowania danych jest możliwa, ale tylko z użyciem klucza szyfrującego.
• Funkcje skrótu – polega na skróceniu dowolnego ciągu znaków do wyrażenia o stałej, określonej długości (dowolnej informacji przydzielany jest unikalny identyfikator). Funkcji tej nie można odwrócić, tak jak w przypadku szyfrowania. Jakkolwiek, znając zakres wartości, jakie zostały poddane skracaniu oraz w jaki sposób zostało ono wykonane, możliwe jest odtworzenie funkcji skrótu i uzyskanie prawidłowego zapisu poprzez tzw. atak siłowy (wypróbowanie wszystkich możliwych kombinacji w celu utworzenia tabel korelacji). Funkcje skrótu można podzielić ze względu na wielkości bloku wyjściowego (ilość bitów). Obecne zalecenia amerykańskiej agencji NIST[1] dotyczące stosowania poszczególnych funkcji skrótu mówią, że do nowych aplikacji zalecane są funkcje skrótu z rodziny SHA-2[2], a w przyszłości funkcja SHA-3[3].
• Do niedawna stosowane były funkcje skrótu MD5[4] oraz SHA-1[5], zostały on jednak wycofane ze względu na niewystarczający poziom bezpieczeństwa.
• Tokenizacja – polega na wykorzystaniu jednokierunkowych mechanizmów szyfrujących opartych na przypisaniu identyfikatora (indeksu, sekwencji lub losowo wygenerowanej liczby) w żaden sposób niezwiązanej z pierwotnymi danymi. Technika ta jest często spotykana w sektorze finansowym do autoryzacji operacji bankowych.

Administratorzy danych osobowych przy doborze technik depersonalizacji powinni kierować się wynikiem analizy ryzyka, a także posiłkować się dostępnymi wskazówkami (Grupa Robocza Art. 29, Wytyczne dotyczące oceny skutków dla ochrony danych oraz ustalenia czy przetwarzanie „z dużym prawdopodobieństwem może powodować wysokie ryzyko”) dobrymi praktykami i normami, jak np. norma ISO/IEC 29134:2017 (Information technology – Security techniques – Guidelines for privacy impact assessment). Warto także wykorzystywać dostępne narzędzia informatyczne (np. http://arx.deidentifier.org/) pozwalające na wykonanie anonimizacji za pomocą rożnych technik oraz ocenę ryzyka naruszenia prywatności zanonimizowanego zbioru.

Techniki depersonalizacji danych posiadają zróżnicowany stopień odporności na czynniki ryzyka.  Wyróżnia się trzy główne ryzyka zagrażające prywatności:

• Wyodrębnienie: jest to możliwość wyizolowania niektórych lub wszystkich rekordów, które identyfikują daną osobę w zbiorze danych.
• Tworzenie powiązań: jest to możliwość powiązania co najmniej dwóch rekordów dotyczących tego samego podmiotu danych (w tej samej bazie danych lub w dwóch różnych bazach danych).
• Wnioskowanie: pozwala z dużym prawdopodobieństwem wydedukować wartość atrybutu z wartości zbioru innych atrybutów.

Ryzykiem związanym z możliwością naruszenia danych osobowych, jest możliwość identyfikacji osoby, której dane dotyczą, dla zbiorów danych zanonimizowanych – z uwagi na zbyt powierzchowną ich anonimizację lub pseudonimizację.

Ryzyko to związane jest z możliwością dokonania przez użytkowników postronnych identyfikacji danych konkretnej osoby, które w ocenie administratora zostały w pełni zanonimizowane bądź zagregowane. Problem ten dotyczy w szczególności danych statystycznych, które w wyniku zbyt dużej szczegółowości oraz w połączeniu ze zbyt małą próbą (np. dotyczącą jednej instytucji, wspólnoty ludzkiej itp.) cechuje podatność, że osoby wchodzące w skład danej wspólnoty mogą przy pomocy powszechnie znanych im informacji o jej członkach, dokonać odkodowania anonimowych informacji. Ponadto, ryzyko identyfikacji danych może nastąpić także poprzez połączenie zanonimizowanego zbioru danych z innymi zbiorami, co w konsekwencji także pozwala na odkodowanie anonimowych informacji. W efekcie może to prowadzić do naruszenia praw osoby, której dane dotyczą.

[1] National Institute of Standards and Technology

[2] SHA-2 składa się z zestawu czterech funkcji dających skróty wielkości 224, 256, 384 lub 512 bitów

[3] SHA-3 funkcja oparta o Algorytm Keccak charakteryzuje się wyższą wydajnością niż SHA-2 zarówno w implementacjach sprzętowych jak i programowych

[4] MD5 – generuje z ciągu danych o dowolnej długości128-bitowy skrót

[5] SHA-1 tworzą 160-bitowy skrót z wiadomości o maksymalnym rozmiarze 264 bitów i jest oparty na podobnych zasadach co MD5

Decyzja Prezesa Urzędu Ochrony Danych Osobowych dotycząca ukarania spółki Morele.net administracyjną sankcją pieniężną w wysokości 2 830 410 zł (co stanowi równowartość 660 000 EUR), wzbudziła w ostatnim tygodniu wiele emocji. Wiemy, że doszło do naruszenia integralności i poufności  danych osobowych ponad 2 milionów klientów ukaranej spółki. Wiemy, że przyczyny tego naruszenia Prezes Urzędu dopatrzył się w lukach dotyczących zabezpieczeń po stronie IT, w stosowanych przez administratora systemach. Spróbujmy przeanalizować, czy faktycznie proponowane przez Urząd działania mogłyby uchronić spółkę przed przykrymi konsekwencjami?

Analiza ryzyka

Jednym z obowiązków administratorów danych jest cykliczne przeprowadzanie analiz ryzyka pod kątem naruszenia praw i wolności podmiotów danych, których dane osobowe administrator przetwarza. Z decyzji dowiadujemy się, że spółka dokonywała doraźnych analiz ryzyka dla poszczególnych procesów przetwarzania danych w sposób niesformalizowany. Sposób ten faktycznie może budzić wątpliwości co do poprawności działania, ze względu na brak powtarzalności oraz możliwości weryfikacji i nadzoru zastosowanych w wyniku takiej analizy ryzyka zabezpieczeń i ich skuteczności.

Co niemniej istotne, z przedstawionych w decyzji informacji wynika, że spółka nie sprawdzała w ramach analizy ryzyka potencjalnych ryzyk dla przetwarzanych danych, ale jedynie badała podatności znane już dla wykorzystywanych w procesie przetwarzania komponentów IT. Bazowanie jedynie na zidentyfikowanych już podatnościach aktywów oraz weryfikowanie skuteczności zastosowanych w celu wyeliminowania tych podatności zabezpieczeń, nie wyczerpuje zakresu analizy ryzyka, którą administratorzy danych zobowiązani są przeprowadzać. Takie podejście mogłoby ograniczać się jedynie do ciągłej weryfikacji, czy podmiot posiada oprogramowanie w wersji aktualnej, co ma wykluczać obciążenie znanymi podatnościami, do których nie dostosowano zabezpieczeń. Do sprawdzania aktualności wersji stosuje się dedykowane skanery, czyli zewnętrzne narzędzia bezpieczeństwa, które służą do wykonania testów bezpieczeństwa – ale to podstawowy element stosowany w ramach testów bezpieczeństwa – i jak powszechnie wiadomo, niewystarczający.

Poza tym, że ograniczanie się do weryfikacji aktualności oprogramowania, jest niewystarczające ze względu na obowiązujące przepisy, należy też pamiętać, że nie dla każdego rodzaju komponentu IT będziemy mogli z łatwości wgrać aktualizację. Zdarza się, że ze względu np. na potrzeby ciągłości działania organizacji, nie jesteśmy w stanie wyłączyć z użycia np. serwera, na którym zapisane jest oprogramowanie, dla którego planujemy aktualizację, gdyż to mogłoby zaburzyć w sposób istotny funkcjonowanie całej spółki. Ten problem można rozwiązać stosując co najmniej kilka warstw zabezpieczających. Przykładowo serwery backend’owe mogą zostać oddzielone od frontend’u za pomocą rozwiązań typu reverse proxy, czyli mechanizmów pośredniczących w ruchu pomiędzy nimi. Dzięki temu podatności wykryte w warstwie backend’owej nie są bezpośrednio narażane na wykorzystanie.

Co jednak z pożądanym zakresem analizy ryzyka? Powinien on poza znanymi podatnościami obejmować także podatności potencjalne, czyli takie, dla których nie mamy już wdrożonych czy zaplanowanych zabezpieczeń, ale w stosunku do których powinniśmy dobierać środki zabezpieczające. Zasadą powinno być opieranie systemu zabezpieczeń na więcej niż jednym mechanizmie  bezpieczeństwa, z uwagi na brak istnienia niezawodnego mechanizmu, zapewniającego bezpieczeństwo w 100%.

Zwiększony ruch na bramie sieciowej

Kolejną kwestią podniesioną przez Urząd, jest niestwierdzenie przez spółkę zwiększonego ruchu na bramie sieciowej w czasie, gdy dochodziło do pobierania bazy danych klientów, pomimo iż spółka deklarowała nieprzerwane monitorowanie ruchu sieciowego w trybie 24/7.

Czy faktycznie za pomocą stosowanego monitoringu ruchu sieciowego można byłoby wykryć włamanie do bazy i zapobiec jego skutkom? Z prostego ćwiczenia (które każdy z nas może przeprowadzić) wynika, że plik tekstowy zawierający 2 miliony rekordów danych logowania zajmuje kilkadziesiąt MB. Przepływ takiego pliku z punktu widzenia monitorowania ruchu sieciowego nawet małej organizacji jest nieistotny. Plik z danymi klientów, wygenerowany w odpowiedzi na zapytanie włamującego i wysłany do niego, powoduje ruch sieciowy zbliżony do tego, jaki generuje kilku użytkowników. Zatem z punktu widzenia monitorowania sieci, trudno byłoby zauważyć coś niepokojącego.

Inaczej zdecydowanie sytuacja przedstawia się z punktu widzenia monitorowania bazy danych. Jedno duże zapytanie, które w odpowiedzi zwróciło jednemu zewnętrznemu użytkownikowi kilka milionów rekordów, powinno zostać zauważone i sprawdzone. Potencjalnym zagrożeniem dla danych osobowych jest możliwość włamania się do bazy z zewnątrz. Włamanie takie może być skutkiem np. odpowiednio zdefiniowanego zapytania w języku SQL, wykorzystującego podatność typu SQL injection. Znane są jednak powszechnie narzędzia służące do wykrywania tego typy ataków, jak również narzędzia do monitorowania zapytań do baz danych. Korzystanie z takich narzędzi, adekwatnych do przetwarzanych danych oraz stosowanych rozwiązań IT, pozwala ograniczyć ryzyko nieuprawnionego dostępu do bazy, a w konsekwencji wycieku danych.

European Union Agency for Cybersecurity (ENISA) opublikowała w listopadzie 2019 r. wytyczne  dotyczące technik i najlepszych praktyk w zakresie pseudonimizacji: https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices

Powstanie raportu związane jest z realnymi problemami i wyzwaniami, obserwowanymi w związku z wdrażaniem pseudonimizacji w praktycznych zastosowaniach.

Wychodząc od kilku scenariuszy pseudonimizacji, wytyczne określają najpierw główne strony, które mogą być zaangażowane w proces pseudonimizacji wraz z ich możliwymi rolami. Następnie analizują różne modele adwersarzy i sposoby ataków na pseudoidentyfikatory, takie jak atak siłowy, atak słownikowy, czy zgadywanie na podstawie informacji pośrednich. Ponadto wytyczne przedstawiają główne techniki pseudonimizacji (np. licznik, generator liczb losowych, kryptograficzna funkcja skrótu, kod uwierzytelniania wiadomości i szyfrowanie) oraz dostępne obecnie podejścia pseudonimizacji (np. pseudonimizacja deterministyczna, częściowo lub w pełni losowa).

W wytycznych omówiono kryteria wyboru właściwych technik pseudonimizacji, takich jak ochrona, skalowalność i odzyskiwanie danych. Analizowane są także konkretne przypadki zastosowania różnych identyfikatorów, takich jak adres IP lub adres e-mail. Omówiony jest również bardziej złożony przypadek zastosowania pseudonimizacji wielu rekordów danych, z analizą możliwości ponownej identyfikacji.

W dokumencie podkreślono, że nie istnieje tylko jedno rozwiązanie lub jeden sposób na wdrożenie pseudonimizacji, który sprawdza się we wszystkich branżach lub we wszystkich scenariuszach zastosowań. Wręcz przeciwnie, prawidłowe zastosowanie pseudonimizacji wymaga wysokiego poziomu kompetencji, aby finalny jej wynik minimalizował zagrożenie atakami kryptologicznymi lub reidentyfikacyjnymi, przy jednoczesnym zachowaniu stopnia użyteczności niezbędnego do przetwarzania danych opatrzonych pseudonimem.

Chociaż wszystkie znane techniki pseudonimizacji mają swoje własne, dobrze zrozumiałe, nieodłączne właściwości, to w praktyce wybór podejścia nie jest trywialnym zadaniem. Należy dokładnie przeanalizować kontekst, w którym ma być stosowana pseudonimizacja, biorąc pod uwagę wszystkie pożądane cele pseudonimizacji (dlaczego tożsamość musi być ukryta, jaka jest pożądana użyteczność pseudonimów, itp.). Przy wyborze właściwej techniki pseudonimizacji należy zatem przyjąć podejście oparte na ryzyku, tak aby właściwie ocenić i zminimalizować zidentyfikowane zagrożenia dla prywatności. W istocie, sama ochrona dodatkowych danych, które są wymagane do ponownej identyfikacji, choć jest warunkiem koniecznym, w niewystarczającym stopniu zapewnia eliminację wszystkich zagrożeń związanych z możliwością depersonalizacji.

Życie w epoce informacji, przenikanie się świata realnego i wirtualnego – niedawno slogany z wizji przyszłości, w ostatnich tygodniach, bardziej niż kiedykolwiek wcześniej, stały się naszym codziennym doświadczeniem. W poszukiwaniu źródeł wartościowych informacji coraz więcej osób bierze udział w webinariach, podczas których wiedzą dzielą się najlepsi specjaliści w swoich dziedzinach.

Jak więc spełnić wymogi prawa, a co więcej – oczekiwania dbających o swoją prywatność i bezpieczeństwo uczestników i zorganizować webinarium zgodnie z rozporządzeniem ogólnym o ochronie danych osobowych (RODO)?

Nowoczesne rozwiązania wymagają nowoczesnego podejścia do przetwarzania danych osobowych. RODO jest nazywane inteligentnym aktem prawnym właśnie dlatego, że ustanowione w nim elastyczne wymogi stosowania środków technicznych i organizacyjnych pozostawiają przestrzeń dla bezpiecznego zaprojektowania nowych procesów przetwarzania danych osobowych.

Planując webinarium zarówno organizator, jak i operator webinarium muszą zadbać o wkomponowanie w ten „produkt” zasad prywatności już na początku jego projektowania – od określenia, jakie dane o uczestnikach będą przetwarzać po szczegóły środków technicznych, jakie zastosują dla zapewnienia bezpiecznej dwustronnej komunikacji. RODO wymaga także ciągłej oceny ryzyka i skutków dla ochrony danych w przypadku ich przetwarzania przy użyciu nowych technologii lub na dużą skalę.

Przed wyborem operatora warto więc przyjrzeć się m.in. w jaki sposób:

• będzie szyfrowane połączenie.
• Użytkownicy mogą zabezpieczyć swój osobisty identyfikator spotkania (PMI).
• Organizator może uniemożliwić dołączenie do webinarium pod imieniem innego uczestnika.

! Organizator, czyli administrator danych osobowych, jest odpowiedzialny za zapewnienie bezpieczeństwa danych uczestników. Dlatego należy z najwyższą ostrożnością wybierać operatorów webinariów. Decydując się na odpowiedni program do realizacji tego przedsięwzięcia, należy dokładnie zapoznać się z regulaminem dostawcy, polityką prywatności a także gdzie i w jaki sposób będą przetwarzane dane osobowe uczestników.

W wypadku naruszenia ochrony danych osobowych uczestników, na szali leży ryzyko wysokiej kary administracyjnej oraz reputacja organizatora. Dlatego warto zwrócić się o pomoc do ekspertów, którzy profesjonalnie zajmują się ochroną danych osobowych i bezpieczeństwem informacji.

Oto kilka wskazówek dla osób koordynujących przetwarzanie danych osobowych w związku z organizowaniem webinarium:

• Nie wysyłaj zaproszeń do udziału w webinarium do osób, które wcześniej nie wyraziły zainteresowania otrzymaniem takiej informacji.
• W formularzu rejestracyjnym wymagaj podania tylko takich informacji, które są niezbędne do realizacji celu (udziału w webinarium) a także takie które będziesz rzeczywiście wykorzystywał – do udziału w niektórych webinariach wystarczające będzie podanie adresu e-mail, ale w innych przypadkach konieczne może być zebranie szerszej kategorii danych, na przykład niezbędnych do przyjęcia płatności, czy potwierdzenia tożsamości. Przydatne może okazać się też uzyskanie nazwy firmy i stanowiska uczestnika, dzięki czemu organizator może lepiej odpowiedzieć na potrzeby audytorium.
• Jeżeli dostęp do webinarium będzie autoryzowany, aby uniknąć udziału osób niezaproszonych, zaplanuj jakich danych osobowych będziesz potrzebować do uwierzytelnienia uczestników. Możliwe, że sam adres e-mail nie będzie wystarczający i przydatny może być także numer telefonu.
• W przejrzysty sposób poinformuj uczestników o przetwarzaniu ich danych i przysługujących im prawach.
• Sprawdź kto jest operatorem usługi webinarium. Jeśli dane zbierane przez formularz elektroniczny mają trafić poza Europejski Obszar Gospodarczy, konieczne będą dodatkowe działania wymagane przez RODO. Do działań tych należy zidentyfikowanie podstawy prawnej legalizującej transfer danych. Ponadto w takim przypadku na organizatorze spoczywa obowiązek poinformowania uczestników webinarium o zamiarze przekazania danych osobowych do państwa trzeciego (poza EOG), o stwierdzeniu przez Komisję Europejską odpowiedniego stopnia ochrony lub o odpowiednich lub właściwych zabezpieczeniach (jeśli decyzja KE nie została wydana dla danego państwa trzeciego) oraz o możliwościach uzyskania przez osobę, której dane dotyczą kopii danych lub o miejscu udostępnienia danych.

Planujesz przesyłać uczestnikowi informacje marketingowe w przyszłości?

W poszukiwaniu właściwej podstawy prawnej legalizującej takie działania w pierwszej kolejności można zbadać, czy zachodzi istotny i odpowiedni rodzaj powiązania między osobą, która uczestniczyła w webinarium, a organizatorem, na przykład czy osoba ta jest stałym klientem organizatora i ma rozsądne przesłanki by spodziewać się, że może nastąpić przetwarzanie jej  danych w celu przedstawienia oferty organizatora. O testach równowagi interesów pisaliśmy tutaj.

Jeżeli jednak ocenisz, że interesy i prawa podstawowe uczestnika mogą być nadrzędne wobec Twojego interesu jako organizatora, w szczególności, gdy osoba ta nie ma rozsądnych przesłanek, by spodziewać się dalszego przetwarzania, możesz pozyskać zgodę na przekazywanie informacji marketingowych w przyszłości oraz na kanał komunikacji, którego chcesz używać.

! Warto przemyśleć kolejność zgód, gdyż zgoda wyłącznie na dany kanał komunikacji (w celu przekazania treści marketingowych) nie stanowi w świetle RODO samodzielnej podstawy legalizującej przetwarzanie danych osobowych w celach marketingowych.

! Upewnij się, że zebrałeś odrębne zgody, spełniające wszystkie wymogi RODO.

! Pamiętaj, że zgodę na przekazywanie informacji handlowych za pośrednictwem e-mail, sms, mms, czy połączeń telefonicznych – należy zebrać również w przypadku, gdy podstawą prawną przetwarzania danych w celach marketingowych jest prawnie uzasadniony interes administratora danych.

Prezes Urzędu Ochrony Danych Osobowych wszczął postępowanie w sprawie Polityki Warszawskiej. Postępowanie zostało wszczęte po zgłoszeniu naruszenia danych osobowych. Od rozpoczęcia obowiązywania RODO minęły właśnie 2 lata. Nic dziwnego, że każde nowe postępowanie czy decyzja organu nadzorczego analizowane są z dużą uwagą. Stanowią one bowiem cenną informację o stanowisku organu nadzorczego o tym na co kładziony jest szczególny nacisk a także o kształtującej się polityce karania.

Przypomnijmy, że obecne postępowanie jest konsekwencją incydentu jaki miał miejsce na początku maja tego roku. Doszło wówczas do wycieku sporej ilości danych studentów i pracowników PW. Jak wynika z doniesień prasowych mogło dojść do ujawnienia szerokiego zakresu danych tych osób takich jak: m.in. imiona, nazwiska, adresy, numery dowodów osobistych, ale także numery PESEL czy informacje o nazwisku panieńskim matki in. Tak szeroki zestaw danych może stwarzać zagrożenie dla osób, których te dane dotyczą. Dane takie jak numer PESEL czy imię nazwisko panieńskie matki stanowią bowiem często jeden z istotnych środków do weryfikacji tożsamości klienta np. w banku. Nieuprawniony dostęp do dużego wachlarza danych rodzi różne ryzyka, w tym m.in. ryzyko kradzieży tożsamości. Warto wspomnieć, że w przy Ministerstwie Cyfryzacji trwają prace Grupy Roboczej powołanej do spraw przeciwdziałania temu zjawisku. W pracach grupy biorą udział przedstawiciele kilku resortów. Obecnie prace grupy uległy czasowemu zawieszeniu z uwagi na trwającą epidemię, ale można mieć nadzieję, że inicjatywa ta przyczyni się do wypracowania rozwiązań mających na celu zmniejszenie skali tego zjawiska.

Z komunikatu UODO wynika, że organ nadzorczy zwrócił się do Politechniki Warszawskiej z prośbą o udzielenie wyjaśnień oraz złożenie dokumentów umożliwiających zbadanie tej sprawy. W ramach postępowania sprawdzone zostanie czy wdrożone zostały odpowiednie środki zabezpieczenia technicznego i organizacyjnego, czy dokonywano ich regularnego przeglądu oraz oceny ich skuteczności w celu zapewnienia bezpieczeństwa danych.

Organ nadzorczy zadeklarował przede wszystkim, że celem postępowania administracyjnego jest przywrócenie u administratora stanu zgodnego z prawem. Jednak w swoim komunikacie UODO zwrócił uwagę także na przysługujące mu uprawnienie do nałożenia administracyjnej kary pieniężnej.

Wyciek danych a także wszczęcie postępowania w tej sprawie zbiegły się ze zwiększeniem popularności komunikacji zdalnej w okresie epidemii – dane pochodziły najprawdopodobniej z platformy służącej do kształcenia na odległość. Zdarzenie to szczególnie uświadamia jak ważne jest zadbanie o odpowiednie środki zabezpieczenia danych w otoczeniu cyfrowym.

Źródła:

https://uodo.gov.pl/pl/138/1545

https://niebezpiecznik.pl/post/uodo-ruszyl-z-postepowaniem-ws-politechniki-warszawskiej/

https://www.rp.pl/Dane-osobowe/305089905-Wyciek-danych-na-Politechnice-Warszawskiej-Uczelnia-chce-zwracac-wydatki-na-BIK.html

European Union Agency for Cybersecurity (ENISA) w opublikowanych w listopadzie 2019 r. wytycznych dotyczących technik i najlepszych praktyk w zakresie pseudonimizacji opisuje praktyczne wskazówki dotyczące pseudonimizacji adresów e-mail.

Adresy e-mail są często używane w serwisach internetowych jako główny identyfikator osoby fizycznej. Ponadto są obecne w wielu bazach danych, w których mogą być również obecne inne identyfikatory – takie numer PESEL. Użytkownicy zazwyczaj używają tego samego adresu e-mail do różnych zastosowań, udostępniając go różnym organizacjom, np. przy zakładaniu kont online. Co więcej, adresy e-mail są często publikowane w Internecie lub można je w niektórych przypadkach odgadnąć. Ze względu na te szczególne cechy, ochrona adresów e-mail jest szczególnie ważna.

Sposób 1: Wykorzystanie liczb losowych

Najprostszym podejściem do pseudonimizacji jest wykorzystanie liczb pseudolosowych. Przy generowaniu pseudonimów możemy wykorzystać dwa podejścia – generowanie liczb losowych (liczby całkowite) ze sprawdzeniem, czy nie pokrywa się ona z dotychczasowymi wpisami, lub też przyporządkowanie adresom numerów zgodnych z pozycją w bazie danych.

Aby zwiększyć właściwości analityczne danych pseudonimizowanych możliwe jest zastępowanie tylko części adresu e-mail. Taki zbieg pozwala na zachowanie wartości informacyjnej niezbędnej np. do prowadzenia analityki, przykładowo w postaci nazwy lub identyfikatora domeny. Wadą staje się jednakże zagrożenie ze strony depersonalizacji adresu e-mail, dlatego przed zastosowaniem metody każdorazowo należy ocenić ryzyka odgadnięcia źródłowego identyfikatora.

Bazując na przykładzie adresu jan.kowalski@domena.pl pseudonimizacja może wyglądać następująco:

• 123 – całość adresu jest zastępowana losowym pseudonimem (najmniejsza wartość informacyjna i największe bezpieczeństwo).
• 123@domena.pl – tylko login jest zastępowany pseudonimem.
• 123@421 – login i domena są zastępowane pseudonimami.
• 123@421.825 – login i składowe domeny są zastępowane pseudonimami (największa wartość informacyjna i największe ryzyko depersonalizacji).

Sposób 2: Wykorzystanie funkcji skrótu

Metoda polega na wykorzystaniu kryptograficznej funkcji skrótu, np. SHA-256, przyporządkowującej każdemu adresowi e-mail inny, unikalny identyfikator. Funkcje skrótu nie są odwracalne, tzn. na podstawie identyfikatora poznanie źródłowego adresu e-mail możliwe jest jedynie przy wykorzystania ataku słownikowego. Ponieważ taki atak jest realnym zagrożeniem dla adresów e-mail, zastosowanie funkcji skrótu możliwe jest tylko w niektórych zastosowaniach, np. do kodowania adresów e-mail na potrzeby wewnętrzne (np. w kontekście działań badawczych) lub jako mechanizm walidacji integralności dla administratora danych.

Sposób 3: Wykorzystanie MAC (Message Authentication Code)

W porównaniu do funkcji skrótu, MAC wykorzystuje dodatkowo sekretny klucz, który w praktyce uniemożliwia wykonanie ataku słownikowego. Oczywiści klucz musi być bezpiecznie przechowywany, ale to samo dotyczy tabeli mapowania pseudo identyfikatorów w Sposobie 1.

Klucze mogą być zmieniane dla tego samego adresu e-mail, aby zwiększyć bezpieczeństwo pseudonimu w różnych zastosowaniach. Tę metodę można także zastosować w scenariuszu, gdy pseudonimizacją zajmuje się inny podmiot niż administrator danych. W takim przypadku podmiot dokonujący pseudonimizacji przechowuje tylko sekretne klucze i w sposób trywialny nie jest w stanie odzyskać pierwotnych identyfikatorów.

Sposób 4: Wykorzystanie szyfrowania

Szyfrowanie, szczególnie z wykorzystaniem algorytmów symetrycznych (deterministyczne), wydaje się bardziej praktyczną metodą niż MAC. Odzyskanie bazowych adresów wymaga jedynie odszyfrowania pseudonimów – nie trzeba przechowywać tabeli mapowania.

Co ciekawe, szyfrowanie asymetryczne (z wykorzystaniem klucza publicznego i prywatnego) nie jest zalecane do pseudonimizacji adresów e-mail (lub innych typów danych, por. ENISA, “Recommendations on shaping technology according to GDPR provisions – An overview on data pseudonymisation”, 2018). Jeśli dokonalibyśmy szyfrowania kluczem publicznym odbiorcy danych, to zakładając, że klucz ten jest zasadzie znany potencjalnemu atakującemu, to może przeprowadzić on atak słownikowy w oparciu o znane (lub domniemane) adresy poczty elektronicznej (podobnie jak w przypadku funkcji skrótu).